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PREFATORY  NOTE 


Force  modernization  and  combat  development  requirements 
have  greatly  increased  the  demand  for  valid  reliability, 
availability,  maintainability  (RAM)  information.  The  scale 
and  diversity  of  these  requirements  implies  the  requirement 
for  the  rapid  data  location,  identification  and  analysis  of 
RAM  information.  Moreover,  extensive  life-cycle  management 
requires  a  RAM  audit  trail  as  the  basis  for  ongoing  materiel 
and  combat  development.  This  need  is  addressed  by  the  TRADOC 
RAM  Data  Evaluation  System  (TRADES). 

The  American  Power  Jet  Company  (APJ)  was  responsible  for 
concept  development;  this  report  covers  requirement  definition, 
assessment  of  alternative  concepts  of  operation,  recommended 
system  operating  characteristics,  and  resource  requirements. 

Work  was  performed  under  Contract  DAAK21-81-C-0034  and  is  docu¬ 
mented  in  five  parts. 

The  present  volume  (Part  I)  comprises  an  Executive  Summary 
and  a  Brief  of  the  detail  material  presented  in  the  other  Parts 
of  this  report.  The  first  chapter  is  self-contained  and  com¬ 
prises  a  short  project  summary,  with  further  details  provided 
in  the  other  chapters.  Analysis  details  incorporating  the 
comments  of  the  SAG,  are  submitted  as  Parts  II  through  V. 

This  work  was  performed  by  the  APJ  project  team  comprised 
of  G.  Chernowitz,  J.M.  Ciccotti,  J.E.  Arnold,  and  R.  Yoshikawa 
(BDM  Corporation).  Report  editing,  preparation  and  issue  were 
capably  handled  by  B.  Boren,  B.  Cavallo,  H.  Wolf,  and  D.  Heidt. 

The  extensive  coverage  of  this  study  involved  the  coopera¬ 
tion  of  many  individuals  in  TRADOC  and  Department  of  Army.  We 
are  particularly  grateful  to  the  representatives  of  the  RAM 
data  users  and  sources  (in  and  out  of  TRADOC)  who  assisted  our 
efforts,  first  with  their  response  to  our  questionnaire  and 
later  in  individual  follow-ups. 

We  also  express  our  appreciation  to  Mr.  C.R.  Lee,  Technical 
Advisor  to  LOGCEN  and  Chairman  of  the  Study  Advisory  Group  (SAG), 
Mr.  Richard  B.  Lindquist,  RAM  Engineering  and  Assessment  Branch, 
Materiel  Systems  Directorate,  Contracting  Officer's  Technical 
Representative,  and  the  members  of  the  SAG  who  contributed  so 
substantially  to  the  quality  of  our  end  products. 


The  final  study  report  has  been  approved  for  distribution 
by  the  Logistics  Center  Commander  as  recommended  by  the  SAG  on 
17  February  1982.  The  following  organizations  were  represented 
on  the  SAG: 

US  Army  Operational  Test  and  Evaluation  Agency, 
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CHAPTER  I 
EXECUTIVE  SUMMARY 


THE  PROBLEM 


Currently,  TRADOC  has  no  organized  Reliability, 
Availability,  and  Maintainability  (RAM)  data  sys- 
ram  tem  which  provides  quick  access  to  the  present-day 

Information  myriad  of  data  sources.  When  data  are  available, 
Gap  lack  of  uniform  reduction  procedures  and  specifics 

of  the  materiel  test  and  field  environment  hampers 
the  accurate  statement  of  future  materiel  require¬ 
ments. 


Critical 

Event 


This  lack  of  key  RAM  information  in  the  TRADOC 
community  was  highlighted  during  a  1  March  1978 
briefing  to  the  Commander,  TRADOC.  The  Commander 
expressed  concern  as  to  how  to  establish  RAM  re¬ 
quirements  on  the  Infantry  Fighting  Vehicle  when 
the  RAM  performance  of  the  current  M113A1  person¬ 
nel  carrier  was  unknown.  He  noted  that  his  staff 
had  repeatedly  tried  to  obtain  RAM  field  data  on 
the  M113A1  without  success.  At  his  request,  the 
LOGC  was  directed  to  try  again  to  obtain  M113A1 
Field  data. 


Subsequent  efforts  provided  test  data  from  a  wide 
variety  of  sources  which  exhibited  large  variances 
Current  because  of  differences  in  environment,  test  purposes. 

Deficiencies  and  failure  definitions  used  for  test  scoring  pur- 
Highlighted  poses.  Field  data  was  extremely  limited,  poorly 

defined,  and  suffered  from  serious  quality  control 
problems.  It  became  clear  that  an  organized  ap¬ 
proach  to  TRADOC’ s  RAM  information  requirements  was 
necessary. 

TRADES  CONCEPT  DEVELOPMENT 

TRADOC  requires  access  to  RAM  data  for  (1)  the  accu¬ 
rate  statement  of  materiel  requirements  and  other 
new  equipment  development  actions,  and  (2)  to  es¬ 
tablish  procedures,  techniques,  and  methodologies 
TRADOC  to  support  the  total  combat  development  mission, 

Requirement  e.g.,  economic  analysis,  logistics  support  planning, 
budgetary  planning,  manpower  determination,  and 
simulations. 


1 
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In  February  1981,  a  contract  was  awarded  to  the 
American  Power  Jet  Company  (APJ)  to  develop  a  con¬ 
cept  for  TRADES  as  an  in-house  information  system 
to  access  computer  and  manipulate  available  engi¬ 
neering,  test,  and  field  RAM  data  and  provide  these 
data  in  a  proper  format  to  support  the  user  mission 
in  materiel  requirements  development,  operational 
and  force  development  testing,  and  materiel  acquisi¬ 
tion. 


Five 
Parts 
to  this 
Study 


The  study  consisted  of  a  series  of  investigations 
which  are  presented  in  this  final  report  as: 

1.  Part  I  -  Executive  Summary  and  Brief  (this  report). 
Includes  an  Executive  Summary  and  highlights  the 
study's  findings,  conclusions,  and  recommenda¬ 
tions  . 

■  2.  Part  II  -  Study  Work  Plan  (SWP).  An  outline  of 
the  study  objectives,  assumptions,  scope,  essen¬ 
tial  elements  of  analysis  (EEA),  time  schedule, 
and  resource  requirements. 


3.  Part  III  -  System  Requirements  Description  (SRD). 
Presents  the  TRADOC  user  requirements  for  the 
TRADES  system,  potential  RAM  data  sources,  and 
their  content  and  accessibility. 


4. 


Part  IV  -  Alternative  Concepts  of  Operation  (ACO). 
Examines  five  alternatives  for  operation  of 
TRADES,  including  merging  TRADES  with  the  Automa¬ 
tic  Data  Processing  Equipment  ( ADPE )  study,  the 
Planning  Factors  Data  Base  (PFDB),  the  Mainte¬ 
nance  Task  Demand  (MTD)  file,  and  two  versions 
of  a  stand-alone  system.  The  recommended  PFDB 
alternative  was  selected  by  the  SAG  for  further 
development . 


5. 


Part  V  -  The  System  Technical  Paper  (STP).  Pro¬ 
vides  further  detail  addressing  the  PFDB  alter¬ 
native  to  include  internal  and  external  proce¬ 


dures,  hardware  and  software  requirements,  and 


personnel  implications  of  the  TRADES  system. 


TRADES 
Coordi¬ 
nation 
with  new 
Army  data 
Systems 


The  development  of  TRADES  is  timely  and  coordinates 
with  data  systems  becoming  available  to  the  Army. 
The  Standard  Army  Maintenance  System  (SAMS)  is 
scheduled  for  full  implementation  by  1984  and 
DARCOM's  Common  Test  Data  Collection  System  (CTDCS) 
is  now  in  implementation.  TRADES  will  provide  the 
unifying  mechanism  to  access  data  previously 
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unobtainable.  The  result  will  be  an  integrated  and 
consistent  treatment  of  RAM  information  with  en¬ 
hanced  flexibility  and  ease  of  operation. 


TRADES  CONCEPT  AND  OPERATION 


The  TRADES  system  concept  incorporates  five  basic 
modules : 

1.  Source  Identification  Module  -  central  repository 
of  RAM  data  sources  in  a  logical  organization  of 
commodities,  identifying  the  form  of  data,  loca¬ 
tion,  extent  of  holdings  and  definitions  for  all 
essential  elements  of  information  (EEI). 


2.  Interface  Module  -  basic  vehicle  to  provide  for 
rapid,  automatic  interface  with  other  data  sys¬ 
tems,  such  as  Defense  Technical  Information  Cen¬ 
ter  (DTIC) ,  SAMS,  CTDCS,  Common  RAM  (COMRAM),  and 
Logistics  Support  Analysis  Record  (LSAR) 


Five 

Operating 

Modules 


3.  Statistical/Analytical  Module  -  a  series  of 
"tools"  to  reduce  raw  data  to  a  form  usable  by 
the  RAM  engineer. 


4.  Quick  Response  Module  -  provides  immediate  "expec 
ted"  value  for  each  EEI  by  item  identification, 
environment  and  life  cycle  stage  (controlled  by 
the  item  proponent). 


5.  Management  Module  -  provides  the  TRADES  Manage¬ 
ment  Branch  the  ability  to  monitor  usage,  update 
other  modules,  maintain  historical  records,  and 
provide  control  over  the  TRADES  process. 


The  five  basic  TRADES  system  modules  are  illustrated 
in  Figure  1-1.  Application  of  these  modules  in  a 
request  flow  diagram  is  illustrated  in  Figure  1-2. 


Figure  1-1.  TRADES  System  Concept  Module 
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Figure  1-2.  TRADES  Request  Flow 
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Description 

of 

Modules 


The  Source  Identification  Module  provides  the  initial 
point  of  contact  for  the  user  query.  At  this  point, 
the  user  can  decide  to  extract  the  "expected"  (work¬ 
ing)  value  from  the  Quick  Response  Module  or  develop 
RAM  data  sources  in  external  automated  data  bases  or 
from  hard  copy.  Where  information  is  available  in 
an  external  automated  data  base,  the  Interface  Module 
provides  the  necessary  software  to  access  the  source 
system  and  extract  the  required  data. 

The  Statistical/Analytical  Module  can  be  used  for 
both  hard  copy  and  automated  data  base  analysis.  A 
series  of  procedures  are  available  which  the  user 
can  select  to  manipulate  ahd  format  the  information 
to  satisfy  his  requirements. 


The  Management  Module  is  used  to  record  frequency 
of  uses,  results  derived,  and  other  information  con¬ 
sidered  desirable  for  management  purposes.  Addi¬ 
tionally,  it  provides  a  history  file  to  maintain 
an  audit  trail  of  RAM  analyses. 

RESOURCE  REQUIREMENTS 

The  TRADES  concept  has  been  developed  to  maximize 
Use  of  use  of  "sunk"  costs  in  equipment  and  software  by  in- 

Existing/  tegrating  TRADES  with  the  PFDB  program  by  using 

Planned  computers  already  on  hand  or  programmed  for  Fort  Lee 

Capabilities  and  Fort  Leavenworth.  Additionally,  TRADES  will 
only  require  additional  terminals  and  some  peri¬ 
pheral  equipment.  The  generic  system  configuration 
of  the  TRADES  concept  in  PFDB  is  shown  in  Figure  1-3. 


Incremental 

Resources 


Incremental  cost  will  include  the  requirement  for  a 
limited  number  of  terminals  and  a  total  of  16  addi¬ 
tional  personnel,  six  in  a  TRADES  Management  Branch, 
one  to  supplement  the  present  data  processing  element 
in  the  LOGC,  and  nine  general  engineers  to  supple¬ 
ment  the  present  RAM  engineers  at  the  TRADOC  schools 
that  indicate  workloads  in  excess  of  present  person¬ 
nel  assignments.  The  increase  in  personnel  would 
enable  TRADOC  activities  to  more  fully  address,  in 
conjunction  with  TRADES,  all  systems  for  which  they 
are  the  proponent  or  the  logistics  oriented  school 


Figure  1-3.  Generic  TRADES  System  Configuration 
( Automat ed  Portion ) 


It  is  projected  that  the  marginal  costs  of  develop¬ 
ment  of  the  PFDB  TRADES  concept  will  approximate 
Incremental  $600,000  exclusive  of  additional  personnel.  This 
Costs  classifies  TRADES  as  a  Class  IV  ADP  -system  which 

will  require  a  Project  Officer  appointed  by  TRADOC, 
with  system  approval  at  TRADOC  level. 


Implemen¬ 

tation 


It  is  projected  that  TRADES  can  be  implemented  dur¬ 
ing  1985  in  accordance  with  the  TRADES  life  cycle 
overview  provided  in  Figure  1-4. 


PRIMARY  CONCLUSIONS  &  RECOMMENDATIONS 


TRADES  Life  Cycle  Management 


Conclusion  1:  TRADES  is  a  viable  concept.  Although 
TRADES  will  not  require  DA  level  approval  (develop¬ 
mental  costs  are  anticipated  to  be  less  than  $3M), 
TRADOC  '  AR  18-1  functions  as  an  umbrella  over  all  Army  auto- 

Can  mation  management.  Therefore,  the  provisions  of 

Approve  this  regulation  must  be  recognized  and  development 

actions  for  TRADES  must  be  within  the  parameters  of 
this  regulation. 


Recommendations :  Initiate  appropriate  life  cycle 
Initiate  management  actions  to  expedite  system  development 
Developmental  in  accordance  with  AR  18-1  and  TB  18-100.  These 
Actions  actions  include: 

a.  Appoint  a  Project  Officer  (PO)  for  TRADES. 

b.  Prepare  a  charter  which  contains  the  specific 
authority  and  responsibility  of  the  PO  for 
getting  the  system  developed  and  deployed. 

c.  Develop  a  Management  Plan  (MP)  within  120  days 
of  appointment  of  the  P0. 

d.  Designate  the  RAM/ Integrated  Logistic  Support 
(ILS)  Division  of  the  U.S.  Army  Logistics  Center 
as  the  Functional  Proponent  (FP)  and  Proponent 
Agent  (PA)  for  TRADES  for  functional  development 
of  TRADES. 
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e.  Designate  the  Planning  Factors  Management  Divi¬ 
sion  (PFMD)  of  the  Logistics  Center  as  Assigned 
Responsible  Agency  (ARA)  for  technical  develop¬ 
ment  of  TRADES.  This  includes  responsibility 
for  production  of  the  ADP  software  that  automates 
the  functional  system. 

f.  Conduct  an  economic  analysis  for  review  at  Mile¬ 
stone  I. 

g.  Initiate  a  System  Decision  Paper  (SDP)  to  forma¬ 
lize  completion  of  the  Concept  Development  Phase 
of  the  TRADES  automation  life  cycle. 

h.  Initiate  a  functional  description  which  would  go 
to  the  level  of  detail  previously  equatable  to 

the  Detailed  Functional  System  Requirements  (DFSR) . 


Management  Tasks 

Conclusion  2:  Other  management  actions  must  also  be 

Initia-  taken  to  ensure  continuity  of  the  TRADES  development 
tion  of  process. 

Management 

Actions  Recommendation :  Initiate  other  management  tasks 

necessary  for  the  TRADES  development  process: 

a.  Organize  a  TRADES  Management  Branch  during  FY  1983. 
This  branch  would  assume  functional  responsibili¬ 
ties  of  the  PM  when  organized. 

b.  Prepare  an  Army  regulation  to  support  data  require¬ 
ments  and  management  responsibilities  for  the 
formalization  of  TRADES. 

c.  Take  full  advantage  of  sunk  costs  by  LOGC  and 
TRADOC  in  the  programming  and  implementation  of 
TRADES. 

d.  Plan  an  implementation  date  of  early  1985  to  adopt 
the  developed  TRADES  System. 

e.  Plan  necessary  personnel  augmentation  to  proponents 


Software 


Conclusion  3:  TRADES  is  designed  to  take  maximum  ad- 
State-of-  vantage  of  state-of-the-art  Data  Base  Management  Sys- 
the-Art  terns  (DBMS)  and  languages.  Commercial  DBMS  should 
Software  be  used.  TRADES  should  minimize  new  software  de¬ 
velopment  to  the  extent  possible  by  using  PFDB  common 
software  and  language. 


Recommendation :  The  use  of  high  order  languages 
should  be  investigated  to  reduce  post-development 
software  support.  TRADES  software  should  achieve, 
to  the  extent  possible,  maximum  ease  of  use  of  the 
capabilities  of  TRADES. 


Hardware 


Utiliza¬ 
tion  of 
Existing/ 
Planned 
Hardware 


Conclusion  4:  The  system  is  planned  to  capitalize 
on  the  latest  available  hardware.  System  design  is 
flexible  enough  to  ensure  that  technological  improve¬ 
ments  to  hardware  are  not  detrimental  to  TRADES. 
Maximum  use  is  made  of  "sunk  costs"  of  hardware 
already  on  hand  or  programmed. 

Recommendation :  Expanded  analysis  capability  at  the 
user  level  through  distributed  micro-computers  is 
actually  an  enhancement  of  TRADES,  and  will  provide 
greater  capability  without  duplicating  the  source 
identification  and  data  storage  capabilities  of 
TRADES.  Updating  these  files,  in  fact,  would  be 
facilitated  through  the  use  of  micro- computers 
where  the  volume  of  data  becomes  sufficient  to  jus¬ 
tify  the  cost. 


SECONDARY  CONCLUSIONS  &  RECOMMENDATIONS 
Hard  Copy  Development 


Need  to 

Retain/ 

Assess/ 

Organize 

Hard 

Copy 


Conclusion  5:  The  evolutionary  development  of  TRADES 
may  most  effectively  be  undertaken  by  taking  steps  to 
avoid  the  continued  loss  of  RAM  data,  and  to  address 
the  problems  of  hard  copy  retention,  identification, 
assessment  and  organization. 

Recommendation:  Initiate  a  limited  data  collection 
effort  to  determine,  as  rapidly  as  possible,  the  ex¬ 
tent,  location  and  accessibility  of  the  TRADOC  hard 
copy  RAM  information.  This  task  could  be  done  in 
conjunction  with  prototyping  to  verify  the  taxonomy 
and  data  extraction  procedures  for  TRADES. 
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Conclusion  6:  An  inherent  characteristic  required 
Prototyp-  of  TRADES  is  that  it  be  capable  of  being  prototyped 
ing  and  permit  its  evolution  in  the  direction  of  maximum 

Advan-  customer  service.  RAM  information  is  not  a  "once  and 
tageous  for  all"  requirement  set  by  current  RAM  requirements 
documents  or  users,  but  are  only  starting  points. 

Recommendation :  Prototyping  is  recommended  for  veri¬ 
fying  interface  procedures,  exercising  manipulation 
and  analysis  routines,  initiating  a  program  for  de¬ 
velopment  of  the  "hard  copy"  data,  and  verifying  the 
categorization  or  taxonomy  technique  of  the  R'tM  data. 

Further,  it  is  recommended  that  prototyping  of  TRADES 
be  initiated  with  a  commodity  area/activity  which  is 
a  current  major  repository  of  RAM  data,  so  that  the 
entire  system  may  be  exercised  and  lessons  learned 
applied  to  create  a  successful  TRADES. 


TRADOC  Test  Data  System 


TRADES 

Requires 

that 

TRADOC 

Test  Data 

not  be 

Dissipated 


Conclusion  7:  There  is  currently  no  common  automa¬ 
ted  system  within  TRADOC  to  capture  raw  data  from 
tests  performed  within  TRADOC.  There  is  a  require¬ 
ment  that  these  test  results  be  an  integral  part  of 
TRADES  and  available  on  an  interactive  basis,  parti¬ 
cularly  during  the  conduct  of  tests  and  to  maintain 
an  audit  trail  of  past  efforts. 

Recommendation :  Investigation  should  be  made  to 

examine  the  development  of  an  exclusive  RAM  test 
data  system  for  use  by  TRADOC  activities. 


Portability 


TRADES 
Design/ 
Develop¬ 
ment 
Must  In 
sure 

Portabil¬ 

ity 


Conclusion  8:  There  are  advantages  to  the  common 
location  of  OAD  and  the  TRADES  functional  activity 
at  the  same  installation,  and  there  is  substantial 
advantage  to  begin  the  operation  with  a  mini-computer. 
Nevertheless,  it  is  also  a  requirement  that  the  system 
be  "portable",  i.e.,  that  the  programs  and  logic  not  be 
computer-peculiar  or  linked  irrevocably  to  another 
system. 
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Recommendat ion :  Specific  attention  should  be  given 
to  insure  that  TRADES  remains  portable  in  its  de¬ 
sign  and  development  characteristics  so  that  it  is 
not  bound  to  one  specific  set  of  hardware. 


CHAPTER  II 
METHODOLOGY 


BACKGROUND 

Increasingly  sophisticated  materiel  acquisition  and 
combat  developmental  processes  are  being  initiated 
by  the  U.S.  Army.  As  a  consequence,  TRADOC  has  a 
requirement  for  better  RAM  information  to  assist 
in  establishing  materiel  requirements,  forecasting 
manpower  authorization  criteria,  inputs  to  simula¬ 
tions,  war  games,  testing  comparisons,  cost  and  ef¬ 
fectiveness  analyses  (COEA),  and  budgetary  planning. 

Recent  Department  of  Army  initiatives  in  the  RAM 
.arena  have  expanded  demands  on  the  TRADOC  RAM  en¬ 
gineers.  These  changing  responsibilities  are  high¬ 
lighted  in  AR  702-3  (Draft),  "Army  Materiel  Reli¬ 
ability,  Availability,  and  Maintainability",  cur¬ 
rently  being  staffed.  TRADOC  responsibilities  for 
RAM  are  set  forth  as  follows: 

1.  Establish  controls  for  RAM  compliance. 

2.  Determine  realistic  RAM  requirements. 

3.  Monitor  RAM  performance  in  development  test  (DT) 
and  operational  test  (OT). 

4.  Establish  liaison  with  materiel  developers  to 
assist  exchange  of  RAM  data  needed  for  emerging 
systems. 

5.  Maintain  a  central  activity  for  proper  statement 
of  RAM  in  materiel  requirements  documents. 

6.  Develop  RAM  methodology  vis-a-vis  combat  develop¬ 
ments  . 

7.  Conduct  OT  to  assess  RAM. 

8.  Review  requests  for  RAM  waivers. 

9.  Provide  RAM  training  for  combat  developers. 

The  basic  purpose  of  TRADES  is  to  provide  the  TRADOC 
RAM  engineer  in  the  combat  development  area  with  the 
tools  to  do  the  required  job.  The  methodology  used 
for  its  development  followed  a  systematic  approach 
to  identify  TRADOC  user  requirements  and  develop 


alternative  concepts  to  satisfy  the  requirement. 
The  overall  TRADES  methodology  map  (Figure  2-1) 
portrays  the  major  steps  taken. 


ESTABLISH  SYSTEM 
REQUIREMENTS  DESCRIPTION 

To  prepare  the  System  Requirements  Description 

(SRD),  several  major  actions  were  performed: 

1.  A  literature  search  included  key  regulatory  docu¬ 
ments  from  DoD,  DA,  and  TRADOC,  as  well  as  exten¬ 
sive  research  into  related  RAM  information  and 
documents . 

2.  Two  comprehensive  questionnaires*  helped  deter¬ 
mine  RAM  requirements  and  data  sources. 

The  first  was  sent  to  all  expected  users  of 
TRADES,  primarily  the  TRADOC  community,  and  other 
agencies,  such  as  HQ  DA,  TRADOC,  and  the  Logis¬ 
tics  Evaluation  Agency.  The  purpose  of  this 
questionnaire  was  to  establish  a  baseline  of  user 
needs,  present  sources,  and  availability /satis¬ 
faction  of  RAM  data. 

A  second  questionnaire  addressed  potential  data 
sources.  Information  was  requested  on  the  source 
RAM  data  base's  automated  or  hard  copy,  extent  of 
RAM  holdings,  accessibility,  methods  of  retrieval, 
and  normal  customers  supported. 

3.  Visits  were  made  to  key  data  users  and  sources  to 
follow-up  on  questionnaire  responses  and  to  ela¬ 
borate  on  required  TRADES  characteristics.  Visits 
were  made  to  DA,  DCSLOG,  DCSRDA,  HQs  TRADOC,  U.S. 
Array  Transportation  School,  U.S.  Army  Training 
Support  Center,  U.S.  Army  Quartermaster  School, 
Logistics  Evaluation  Agency,  HQs  DARCOM,  Materiel 
Readiness  Support  Activity,  U.S.  Army  Central  Test 
Measurement  and  Diagnostic  Equipment  Activity,  U.S 
Army  Quality  Arsurance  Field  Activity,  U.S.  Army 
Materiel  Systems  Analysis  Agency,  U.S.  Army  Ordi¬ 
nance  Center  and  School,  PM  SMOKE,  U.S.  Army  Mo¬ 
bility  Equipment  Research  and  Development  Command, 
U.S.  Army  Engineer  School,  U.S.  Army  Operational 
Test  and  Evaluation  Agency,  and  U.S.  Army  Test  and 
Evaluation  Command. 


♦See  Part  III,  SRD,  for  questionnaire  contents  and  explicit 
results. 
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•  These  visits  yielded  valuable  insights  into  the 
procedural  aspects  and  availability  of  RAM  infor¬ 
mation.  The  immense  variety  of  sources  and  form 
of  data  available  became  apparent,  and  underscored 
the  need  for  a  unified  RAM  evaluation  system. 

ESSENTIAL  ELEMENTS  OF 
ANALYSIS  (EEAs ) 

The  following  EEAs  were  established  to  evaluate  the 
various  alternatives: 

1.  Responsiveness  to  TRADOC  user  requirements 

2.  Accessibility  to  proponents 

3.  Essential  Elements  of  Information  (EEIs) 

.4.  Flexibility  (batch  vs  interactive) 

5.  Integration  with  other  systems 

6.  Backup  capability 

7.  Growth  potential 

8.  Quality  control 

9.  Security  -  software  and  data  base 

10.  Implementation  time 

11.  Resource  requirements: 

a.  Investment 

b.  Operating 

ALTERNATIVE  CONCEPTS 
OF  OPERATION  (ACO) 

It  was  necessary  to  develop  a  methodology  for  com¬ 
paring  the  alternatives  developed.  Of  the  avail¬ 
able  techniques,  it  was  considered  most  advantageous 
to  develop  alternatives  that  would  satisfy  the  EEAs 
previously  described,  and  then  measure  the  resulting 
differences  in  resource  requirements  and  implementa¬ 
tion  time  implied  by  each  approach. 


CHAPTER  III 
SYSTEM  REQUIREMENTS 


This  chapter  summarizes  the  system  requirements  for 
TRADES,  documented  in  the  System  Requirements  Des¬ 
cription  (SRD),  Part  III  of  this  report*. 

TRADES  OBJECTIVES 

The  basic  purpose  of  TRADES  is  to  provide  a  system 
that  TRADOC  and  its  materiel  proponents  can  use  to 
locate,  identify,  collect,  analyze,  validate,  store, 
retrieve,  process  and  disseminate  RAM  information 
using  units  of  measure  and  methods  of  presentation 
compatible  with  TRADOC  proponent  requirements. 
Furthermore,  TRADES  must  be  able  to  satisfy  user 
requirements  in  a  timely  manner  and  within  realis¬ 
tic  availability  of  information  provided  by  RAM  data 
sources . 

Thus,  TRADES  provides  an  interface  and  analysis  sys¬ 
tem  facilitating  the  exchange  of  information  be¬ 
tween  RAM  sources  and  RAM  data  users.  The  follow¬ 
ing  provides  a  description  of  system  characteristics 
requirements  used  as  the  basis  for  developing  ACOs 
(Part  IV  of  this  report). 

RESPONSIVENESS  TO  TRADOC 
USER  REQUIREMENTS 

The  TRADES  functional  requirements  to  satisfy  the 
TRADOC  users  were  addressed  from  five  key  aspects: 

1.  Turnaround  time  requirements 

2.  Level  of  data  required 

3.  Data  form 

4.  Statistical  and  analytical  manipulation 

5.  Application  of  defined  factors  to  modify  RAM  data 

TRADES  system  requirements  presented  below  were  de¬ 
veloped  from  the  responses  received  from  user  ques¬ 
tionnaires  covering  each  subject  area. 


♦Data  source  characteristics  are  extensively  covered  in 
Part  III. 


At  the  outset,  it  was  determined  from  the  question¬ 
naire  replies  that  user  needs  are  such  that  recurring 
reports  are  not  appropriate.  Rather,  outputs  tailored 
specifically  to  user  requests  as  to  materiel  scope 
and  detail  are  required.  Certain  reports  needed  for 
TRADES  management  may,  however,  be  required  on  a  re¬ 
curring  and  fixed  format  basis. 

TURNAROUND  TIME 
REQUIREMENTS 

When  a  requirement  exists  for  RAM  data,  24%  of  all 
respondees  require  the  information  in  less  than  one 
week.  An  additional  32%  (for  a  total  of  56%)  require 
RAM  data  within  one  month  of  the  time  the  request  is 
initiated.  Further,  research  also  revealed  a  re¬ 
quirement  for  extremely  rapid  retrieval  and  verifica¬ 
tion  (less  then  24  hours)  in  preparation  for  major 
decision  reviews. 

To  be  responsive  to  the  user's  requirement,  TRADES 
must  therefore  be  interactive,  capable  of  responding 
to  urgent  requirements  as  well  as  routine  requests. 

RAM  DATA  FORM 

94%  of  all  TRADOC  users  require  field  experience  re¬ 
duced  data.  83%  require  field  experience  data  based 
on  user  mission.  83-94%  require  test  data  in  some 
form.  89%  need  data  from  specification  and  require¬ 
ments  documents. 

QUICK  RESPONSE 
CONSIDERATIONS 

Responses  to  user  questionnaires,  verified  by  on-site 
interviews  at  selected  activities,  indicate  a  scar¬ 
city  of  RAM  data  to  satisfy  specific  user  require¬ 
ments  for  many  of  the  older  equipments  now  being  re¬ 
placed.  As  new  equipment  is  developed,  early  data 
is  often  of  limited  value  in  predicting  life  cycle 


Based  on  this,  there  is  a  requirement  to  establish 
an  "expected  value(s)"  for  applicable  RAM  data  ele 
ments  on  items  of  Army  materiel  of  interest  to 
TRADOC  proponents.  Such  expected  values  (properly 
identified  and  with  appropriate  caveats)  could  be 
used  in  lieu  of  a  substantiated  data  base  and  re¬ 
fined  as  additional  data  become  available. 

ACCESSIBILITY  TO 
PROPONENTS 

Less  than  50%  of  the  user  responses  indicated  the 
present  availability  of  a  terminal  within  their 
activity.  However,  within  the  present  state  of 
technology  and  cost,  terminal  purchase  involves 
a  minor  commitment  of  resources. 

ESSENTIAL  ELEMENTS  OF 
INFORMATION  (EE I) 

A  total  of  33  EEIs  were  developed  from  the  user 
questionnaires.  These  EEIs  satisfied  the  require¬ 
ments  of  AR  702-3,  the  RAM  Rationale  Annex  Hand¬ 
book,  as  well  as  other  reliability  requirements. 

Of  this  total,  the  nine  central  requirements  in¬ 
dicated  by  the  user  activities  may  be  summarized 
as  follows: 

1.  Reliability: 

a.  Mean  Time  between  Failures  ( MTBF ) 

b.  Mean  Time  between  Operational  Mission 

Failures  ( MTBOMF ) 

c.  Mean  Time  between  Unscheduled  Maintenance 

Actions  ( MTBUMA ) 

d.  Probability  of  mission  success. 

2.  Availability: 

a.  Operational  availability/system  readiness 

objectives 

b.  Utilization  rates 


3.  Maintainability: 

a.  Mean  time  to  Repair  (MTTR) 

b.  Maintenance  ratio 

c.  Logistic  downtime. 

It  has  been  suggested  that  these  nine  EEIs  be  used 
to  initialize  the  TRADES  system.  However,  TRADES  is 
designed  with  the  capability  of  satisfying  all  user 
EEI  requirements  as  part  of  its  maturing  process. 

FLEXIBILITY 

The  anticipated  workload  of  the  TRADES  system  permits 
a  consideration  of  batch  processing.  However,  be¬ 
cause  of  the  responsiveness  required  of  the  system, 
-TRADES  must  be  flexible  enough  to  provide  for  inter¬ 
active  capability. 

INTEGRATION  WITH  OTHER 
SYSTEMS 

TRADES  has  the  function  of  interfacing  with  RAM  data 
sources  and  repositories  of  related  information. 

The  wide  diversity  of  ADP  equipments  and  systems 
used  in  such  systems  results  in  significant  dif¬ 
ferences  in  programming  languages,  machine  inter¬ 
face  characteristics,  etc.  TRADES  must  provide 
adequate  guidance  to  its  users  to  permit  entry  and 
use  of  the  different  software  packages  and  hardware 
systems. 

BACKUP  CAPABILITY 

Backup  capability  to  the  TRADES  system  is  provided 
at  three  levels : 

1.  A  TRADES  office  within  USALOGC 

2.  Use  of  expected  values  described  above 

3.  Hardware  backup  of  LOGC  by  DPFO. 

HARD  COPY/AUTOMATED 
ENVIRONMENT 

The  ultimate  goal  of  the  overall  program  is  to  es¬ 
tablish  a  major  RAM  information  system  that  will 
satisfy  user  requirements  in  minimum  response  time. 


It  must  be  recognized,  however,  that  for  several 
years,  the  system  will  be  operating  in  a  mixed  hard 
copy  environment  which  is  only  lightly  automated, 
and  moving  toward  a  state  where  hard  copy  is  less 
important  than  automated  data.  In  either  case, 
hard  copy  must  be  recognized  as  being  involved  in 
RAM  data  somewhere  in  the  system  at  all  times. 

A  major  issue  to  be  resolved  is  the  disposition  to 
be  made  of  existing  and  newly  generated  hard  copy 
data.  One  approach  might  be  to  leave  it  in  its 
present  physical  location,  with  provisions  to  keep 
it  from  being  destroyed  until  it  is  no  longer  use¬ 
ful  to  RAM  analyses . 

An  alternative  would  be  to  maintain  a  central  TRADES 
repository  of  all  hard  copy  not  formally  inventoried 
in  major  hard  copy  data  holdings  with  instructions 
issued  for  these  holdings  to  be  forwarded  to  the 
central  repository. 

The  third  concept  would  be  to  provide  current  organ¬ 
ized  data  systems,  (e.g. ,  DTIC/Defense  Logistics 
Services  Information  Exchange  (DLSIE))  with  the 
opportunity  to  index  and  inventory  all  holdings  not 
currently  in  their  files. 

On  the  basis  of  the  above,  the  development  of  the 
Source  Identification  Module  would  include  major 
tasks  of : 

1.  Indexing  existing  hard  copy  reports  into  the 
TRADES  Source  Identification  Module. 

2.  Providing  adequate  information  for  each  of  the 
source  documents  (hard  copy  reports)  that  will 
provide  the  potential  user  with  adequate  infor¬ 
mation  to  determine  the  usefulness  of  each  test 
report  to  his  requirement. 

3.  Enter  extracted  key  RAM  reference  data  into  the 
TRADES  system,  thereby  reducing  response  time 
and  narrowing  the  degree  of  hard  copy  search. 


DATA  SOURCES 


The  initial  repository  of  RAM  data  in  TRADES  will 
be  heavily  weighted  by  the  volume  of  test  data 
available  through  TECOM,  OTEA,  TRADOC  Schools, 

Centers  and  Boards,  and  the  PMs'  Offices  (both 
TRADOC  and  DARCOM  Managers).  Current  plans  for  a 
full-scale  implementation  of  CTDCS  and  SAMS-1,  2, 
and  3,  plus  wholesale  SAMS,  provide  a  basis  for 
large-scale  introduction  of  automated  RAM  data 
bases  into  TRADES  in  the  1983-1985  timeframe. 

GROWTH  POTENTIAL 

TRADES  should  have  a  growth  potential  to  absorb  in¬ 
telligence  from  the  major  data  systems  noted  above, 
as  well  as  growth  in  the  software  packages  to  allow 
•users  to  extract  RAM  data  in  a  form  to  support  the  RAM 
engineers  in  their  functions. 

The  TRADES  software  packages  should  be  modular  in 
concept,  using  the  concept  of  master  or  executive 
program  for  identification  and  call-up  of  required 
modules  suitable  for  a  particular  user  application. 

The  Interface  Module  can  be  modified  to  accommodate 
additional  data  systems  and  data  bases,  and  each 
other  functional  module  of  TRADES  must  be  designed 
for  ease  of  modification  and  growth  (structured 
programming) . 

It  is  essential  that  provisions  be  made  for  quality 
control  of  all  input  data  with  both  edit  and 
validity  checks  to  be  made  periodically  as  update 
procedures  are  applied.  Quality  control  provisions 
especially  apply  to  expected  values. 

SECURITY  OF  SOFTWARE 
AND  DATA  BASE 

Although  TRADES  is  user-oriented,  it  is  essential 
that  security  be  maintained  on  pre-packaged  soft¬ 
ware  modules  and  the  data  base  itself.  Since  users 
will  have  access  to  the  data  base  for  identification 
of  RAM  data  sources,  any  changes,  updates,  edits, 
corrections,  etc.,  should  be  performed  by  a  function 
centralized  within  the  TRADES  Office.  TRADES  system 
changes  by  activities  outside  the  TRADES  Office 
would  risk  confusion  and  error. 


This  security  should  not,  however,  prevent  the 
application  of  software  modules  for  manipulation  and 
analysis  of  data  elements  which  are  drawn  into  the 
TRADES  system  from  external  sources.  Techniques  and 
procedures  are  available  within  the  current  state-of- 
the-art  to  permit  such  manipulations  to  be  performed 
external  to  the  data  base  itself,  so  that  the  data 
base  remains  intact  for  other  users . 

Access  security  should  be  maintained  by  appropri¬ 
ate  password  and  identifiers. 

Security  of  classified  data  may  be  maintained  by 
use  of  secure  lines  and  (as  required)  encipherment 
and  scrambling. 

IMPLEMENTATION  TIME 

Selected  alternatives  need  to  be  measured  in  terms 
of  total  forecasted  implementation  time.  These 
times,  along  with  resource  requirements,  are  instru¬ 
mental  in  the  selection  of  a  proposed  alternative. 

RESOURCE  REQUIREMENTS 

Total  resource  requirements  for  application  of 
TRADES  can  best  be  measured  by  the  relative  volume 
of  demands  anticipated  for  TRADES. 

Each  of  the  selected  potential  TRADES  users  were 
queried  as  to  the  frequency  of  their  RAM  data  re¬ 
quirements.  Based  on  their  responses,  extrapolated 
to  the  total  TRADOC  community,  it  is  forecast  that 
an  average  daily  demand  of  75  requests  will  be  made 
against  a  mature  TRADES  system,  or  a  total  of  20,000 
actions  per  year  by  the  TRADOC  community.  Early  in¬ 
dications  from  interviews  with  DARCOM  activities 
indicate  at  least  a  parallel  requirement  from  the 
DARCOM  PMs  and  test  agencies.  This  implies  a  total 
annual  demand  of  approximately  40,000  requests  on 
TRADES,  or  160  per  day. 

Consideration  must  be  given  to  hardware,  software, 
and  personnel  costs,  based  on  the  above  indicated 
workload.  (It  should  be  noted  that  this  projected 
workload  is  used  throughout  the  STP  (Part  V)  for 
determining  requirements.) 


A 
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CHAPTER  IV 
ALTERNATIVES  CONSIDERED 


GENERAL 


The  alternatives  considered  are  explained  in  detail 

in  the  ACO,  Part  IV  to  this  final  report.  These 

alternatives  were: 

1.  Planning  Factors  Data  Base  (PFDB)  -  is  currently 
under  development  by  the  LOGC.  This  alternative 
would  feature  time-sharing  process  with  a  LOGC 
minicomputer  (to  be  selected)  with  back-up  per¬ 
formed  by  the  large  mainframe  (UNIVAC  1100/82) 
at  DPFO.  The  connecting  link  with  TRADES  is 
that  PFDB  currently  acts  as  a  unifying  umbrella 
over  a  number  of  other  logistic  systems  at  the 
LOGC. 

2.  Maintenance  Task  Demand  (MTD)  -  is  a  system  cur¬ 
rently  operating  at  DPFO  with  the  LOGC  as  execu¬ 
tive  agent.  There  are  a  limited  number  of  weapons 
systems  on  MTD  at  present,  and  less  than  5%  of 
the  automated  data  entries  are  estimated  to  be 
the  same  as  those  projected  for  TRADES. 

3.  Automatic  Data  Processing  Equipment  ( ADPE )  -  was 
an  overall  analysis  of  LOGC  ADPE  requirements. 

This  alternative  implied  that  TRADES  time-share 
on  a  minicomputer  with  LOGEX.  The  major  disad¬ 
vantage  of  this  system  is  the  non-availability  of 
the  computer  during  the  LOGEX  annual  training  ex¬ 
ercise,  as  well  as  the  minimal  relationships  be¬ 
tween  LOGEX  and  TRADES  subject  content. 

4.  Stand-Alone  Minicomputer  (SAMI)  -  essentially 
considers  a  separate  system  (similar  to  PFDB) 
without,  however,  any  relationship  to  any  other 
system. 

5.  Stand-Alone  Mainframe  (SAMF)  -  envisions  a  single 
system  located  at  DPFO,  accessed  on  the  same 
basis  as  the  other  systems,  but  not  associated 
with  any  other  system  such  as  MTD  or  PFDB. 


4-1 


Table  4-1  compares  the  alternatives  against  the  EEA 
set  forth  in  the  Methodology  (Chapter  II).  In  es¬ 
sence,  there  was  little  difference  among  the  various 
ACOs,  since  the  plan  for  each  ACO  was  to  create  a 
nearly  equal  capability. 

The  estimated  developmental  cost  comparisons  (ex¬ 
cluding  school  requirements  for  personnel)  are 
shown  in  Table  4-2.  Supplementary  RAM  engineers  re¬ 
quired  by  the  various  TRADOC  schools  and  centers 
were  not  included  as  they  reflect  a  constant  element 
applicable  to  all  alternatives. 

Implementation  Time 

To  properly  assess  this  EEA,  certain  fundamental  as¬ 
sumptions  were  accepted: 

1.  TRADES  will  be  categorized  as  a  Class  IV  ADP 
system  per  AR  18-1. 

2.  The  MTD  and  SAMF  ACOs,  if  selected,  would  be  de¬ 
signed  to  reside  on  the  UNIVAC  1100  Series  ADP 
system  at  the  TRADOC  DPFO,  Fort  Leavenworth, 
Kansas . 

3.  The  PFDB,  ADPE  and  SAMI  ACOs,  if  selected,  would 
be  designed  to  reside  on  the  Operations  Analysis 
Directorate  (OAD)  minicomputers  planned  for  pro¬ 
curement  and  must  have  the  DPFO  available  for 
backup  for  work  overflow  during  peak  work  efforts 

4.  The  primary  responsibility  for  operational  sup¬ 
port  of  TRADES  will  be  assigned  to  an  existing 
division/branch  of  LOGC  as  an  additional  func¬ 
tion. 


In  general,  implementation  time  for  the  PFDB,  ADPE, 
and  stand-alone  ACOs  should  be  equivalent.  Since 
development  effort  for  all  ACOs  will  be  in  excess 
of  $100,000  (but  under  $3M),  they  fall  within  a 
Class  IV  ADP,  require  a  manager  or  project  officer 
appointed  by  TRADOC,  with  system  approval  at  TRADOC 
level . 
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DEVELOPMENT 


Software 

Facilities 

Hardware 


TOTAL 


$619.6 


$554.3  $619.6  $612.6  $604.3 


OPERATING  (ANNUAL) 
Personnel** 
Facilities 
Hardware 


TOTAL 


$236.7 

1.5 

.7 


$238.9 


$200.0 

1.3 

10.8 


$236.7 

1.5 

.7 


$212.1  $238.9 


$200.0 

1.3 

.7 


$202.0  $212.1 


*1981  dollars;  not  rounded  to  preserve  audit  trail. 
**Excludes  additional  school  personnel. 


In  accordance  with  Table  4-3,  TRADES  could  be  imple¬ 
mented  during  calendar  year  (and  fiscal  year)  1985. 
Rigid  adherence  to  the  approval  and  administrative 
cycles  is  required  in  order  to  provide  the  software 
developer  adequate  time  to  complete  the  process. 
Software  development  incorporates  system  design  to 
the  level  of  programming,  debugging,  prototyping, 
and  system  demonstration. 

TABLE  4-3.  ACO  COMPARISONS  -  TYPICAL  IMPLEMENTATION 
SCHEDULES 


LIFE  CYCLE  STAGE 

MTD 

PFDB,  ADPE, 
SAMI,  SAMF 

ACO  Final  Report 

Feb.  1982 

TRAD0C  Approval 
(Class  IV  System) 

Aug.  1982 

Aug.  1982 

Date  of  Contract  - 
Software  Development 

March  1982 

March  1982 

System  Design  & 
Development  Completion 

r 

Dec.  1984 

March  1985 

The  difference  in  implementation  time  for  MTD  is 
attributable  to  a  minor  savings  of  programming, 
debugging,  and  prototyping. 

THE  SELECTED  SYSTEM 

The  PFDB  alternative  was  the  system  recommended  by 
APJ,  and  agreed  to  by  the  SAG.  The  primary  reason 
for  the  selection  of  the  PFDB  was  the  administra¬ 
tive  support  provided  by  the  Planning  Factors  Divi¬ 
sion  of  the  LOGC,  and  the  high  degree  of  relation¬ 
ship  of  PFDB  with  TRADES.  (The  cost  and  implementa 
tion  time  variances  among  alternatives  were  not 
significant  enough  to  justify  a  clear  choice  based 
on  those  factors  alone.) 


CHAPTER  V 
TRADES  SYSTEM  CONCEPT 


ORGANIZATION  AND  LOGICAL 
STRUCTURE 


The  TRADES  system  concept  envisions  five  modular 
functional  elements  as  shown  in  Figure  5-1.  The 
following  descriptions  of  the  modules  serve  the 
purpose  of  exposition  and  demonstration,  and  do  not 
necessarily  represent  the  file  structure  which  will 
be  developed  in  the  design  phase  of  the  TRADES  life 
cycle  development  process.  The  TRADES  concept  is 
more  fully  explained  in  the  STP,  Part  V  to  the 
Final  Report. 

Module  Descriptors 

The  Source  Identification  Module  is  a  major  element 
of  TRADES  and  will  be  the  one  most  frequently  ac¬ 
cessed.  Through  the  Source  Identification  Module, 
the  user  will  interactively  query  TRADES  via  a  ter¬ 
minal  for  the  immediate  determination  of  RAM  data 
information  sources.  Responses  will  include  the  ap¬ 
propriate  information  (see  Table  5-1)  based  on  user 
requirements . 

After  TRADES  is  initiated,  information  will  be  input 
from  test,  field,  or  engineering  sources.  Where  ap¬ 
propriate,  the  item  proponent  may  choose  to  enter  an 
expected  value  in  the  Quick  Response  Module  (see 
Table  5-2).  In  these  cases,  values  are  then  immedi¬ 
ately  available  to  users  in  an  immediate  response 
mode.  Such  values  will  be  defined  by  mission,  geo¬ 
graphical  conditions,  and  other  appropriate  modifiers. 
Values  in  the  Quick  Response  Module  are  controlled  by 
TRADOC  proponents,  and  may  be  a  calculated  value  from 
the  field  or  tests,  or  "expected"  value  based  on  a 
process  which  is  recorded  in  the  associated  qualifiers 

The  Interface  Module  (Table  5-3)  will  provide  for 
rapid,  automatic  interface  with  other  automated  data 
systems,  such  as  DTIC,  SAMS,  COMRAM,  CTDCS,  and  LSAR. 
The  development  of  these  interfaces  will  require  a 
major  proportion  of  the  development  and  later,  system 
maintenance  effort  to  ensure  interface  capabilities 
with  other  systems. 


Source 


Figure  5-1.  TRADES  System  Concept  Module 


TABLE  5-1.  SOURCE  IDENTIFICATION  MODULE  DESCRIPTION 


o  Central  repository  of  RAM  data  sources 
o  Logical  organization  of  taxonomy  of  commodities: 

-  End  item 

-  Major  Subsystems 

-  Selected  Components 

-  Test  and  support  equipment 
Consistent  with  TM  38-750 

o  Identifies: 

-  Agency  with  appropriate  RAM  data  holdings 

-  Form  of  data  (e.g.,  hard  copy,  automated,  secure) 

-  Extent  of  holdings  (e.g.,  years  of  information, 

numbers  of  reports) 

-  Form  of  data  (e.g.,  test,  raw  field,  reduced) 

-  Environmental  condition  (e.g.,  peacetime,  geographical 

arctic) 

-  Essential  elements  of  information  (EEI) 


TABLE  5-2.  QUICK  RESPONSE  MODULE  DESCRIPTION 


o  Provides  immediate  "expected"  value  for  each 
EEI  by  item  identification,  environment,  and 
life  cycle  stage. 


o  Values  controlled  by  proponent  activities. 


TABLE  5-3.  INTERFACE  MODULE  DESCRIPTION 


o  Protocol  to  communicate  with  source 
computers 

o  Vehicle  to  extract,  analyze,  and  format 
outputs  from  automated  data  sources 


The  Statistical/Analytical  Module  (Table  5-4)  pro¬ 
vides  the  user  with  a  series  of  "tools"  to  analyze 
raw  data,  or  to  combine  the  results  of  different 
inputs  to  make  the  maximum  proper  inference  and  a 
directly  usable  product  for  the  RAM  engineer. 


TABLE  5-4.  STATISTICAL/ ANALYTICAL  MODULE  DESCRIPTION 

o  Extract  data 

o  Formulate  tables 

o  Carry  out  regressions  or  time 
series  analyses 

o  Other  statistical  manipulations 


The  Management  Module  (Table  5-5)  provides  the  abil¬ 
ity  for  the  TRADES  Management  Branch  to  monitor  usage, 
update  the  other  modules,  maintain  historical  records, 
and  provide  control  over  the  TRADES  process. 

TABLE  5-5.  MANAGEMENT  MODULE  DESCRIPTION 


o  Provides  basis  for  updating  and  developing 
other  modules 

o  Provides  an  audit  trail  of  TRADES  use 

o  Provides  proponents  a  method  to  record 
procedural  notes. 
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TRADES  REQUEST  FLOW 


Figure  5-2  illustrates  a  typical  TRADES  request  flow, 
beginning  with  a  user  query.  Information  from  the 
Source  Identification  Module  directs  the  user  to  the 
Quick  Response  Module  for  an  immediate  "expected" 
value  response,  if  that  is  desired  (I).  If  refer¬ 
ence  is  made  to  hard  copy  reports,  information  is 
provided  on  procedures  to  obtain  them  (II).  In  the 
event  that  RAM  data  is  available  in  an  external  auto¬ 
mated  data  base,  the  Interface  Module  serves  to 
facilitate  extraction  of  the  required  EEI  and  sup¬ 
porting  information  (III).  In  all  cases,  data  may 
be  processed  using  the  Statistical/Analytical  Module 
to  determine  needed  values  and  relationships. 

Additionally,  the  Management  Module  records  each 
-  transaction  to  develop  use  frequency,  audit  trails 
and  a  historical  file  of  outputs.  The  Management 
Module  also  provides  the  vehicle  for  update  of  the 
RAM  information,  program  software  and  assistance  to 
TRADES  users. 

PERSONNEL  REQUIREMENTS 

As  a  logical  part  of  the  implementing  TRADES,  con¬ 
sideration  must  be  given  to  organizing  a  TRADES 
Management  Branch  within  the  USALOGC.  This  branch 
would  have  the  following  major  functions: 

1.  TRADES  system  management 

2.  Methodological  and  analysis  support 

3.  Source  and  user  service. 

Additionally,  certain  high  volume  users  within  TRADOC 
should  have  additional  personnel  assigned.  These 
recommendations  are  based  on  anticipated  proponency 
workload  within  the  TRADES  system. 

Table  5-6  summarizes  the  total  additional  TRADOC  per¬ 
sonnel  resources  for  TRADES  implementation,  noting 
location  and  job  description. 


USER  QUERY 


Figure  5-2.  TRADES  Request  Flow 


TABLE  5-6.  TOTAL  TRADES  TJiADOC  PERSONNEL  REQUIREMENT, 


USERS 

DESCRIPTION 

OCS 

General  Engineer  (RAM) 

TSCH 

General  Engineer  (RAM) 

MMCS 

General  Engineer  (RAM) 

FAS 

General  Engineer  (RAM) 

INS 

General  Engineer  (RAM) 

SIGS 

General  Engineer  (RAM) 

ENS 

General  Engineer  (RAM) 

AVNS 

General  Engineer  (RAM) 

ADS 

General  Engineer  (RAM) 

TRADES  MANAGEMENT  BRANCH  (RAM/ILS  DIV.) 

LOGC 

Supervisory  General  Engineer  (RAM) 

LOGC 

Analysts/Statisticians 

LOGC 

Computer  Specialist  (Sys  Anl) 

LOGC 

General  Engineer  (RAM) 

LOGC 

Clerk  Typist 

DATA  PROCESSING  ELEMENT  (Planning  Factors  Div.) 

LOGC 

Senior  Programmer 

SOURCES 

No  quantified  estimates  have  been  made. 

While  TRADES  is  expected  to  increase  the  efficiency 
of  TRADOC  RAM  engineers,  it  is  not  likely  that  per¬ 
sonnel  reductions  will  occur  as  a  result  of  TRADES. 
This  is  a  preliminary  estimate,  subject  to  detail 
analysis  during  the  TRADES  implementation  process. 


HARDWARE  REQUIREMENTS 


The  TRADES  operating  system  is  shown  in  Figure  5-3, 
as  part  of  the  PFDB  system.  The  point  has  been 
made  that  TRADES  capitalizes  on  sunk  costs  of  both 
personnel  and  computer  equipment  programmed  for  the 
PFDB.  Of  the  total  system  shown,  the  only  equipment 
that  would  require  separate  purchase  is  approximately 
twenty  terminals  with  line  printers  and  multiplexers. 


Other  costs  are  minor,  such  as  additional  tapes  or 
disks,  and  facilities  requirements,  such  as  desks. 
These  have  been  identified  in  Parts  IV  (ACO)  and  V 
(STP).  Table  5-7  lists  the  primary  hardware  items 
used  by  the  TRADES  system. 

TRADES  CAPABILITIES 

The  resulting  capabilities  of  the  TRADES  system, 
as  conceptualized,  are  summarized  as  follows: 

1.  Real-time  access  to  automated  data  systems 

2.  Directory  service  for  both  automated  and  hard 
copy  data 

3.  Rapid  data  reduction,  analysis  and  manipulation 

4.  Historical  record  of  output  data  provided. 


TABLE  5-7.  HARDWARE  OVERVIEW 


HARDWARE 

CONCEPT  CHARACTERISTICS 

Mainframe 

Time  share  with  DPFO  large  mainframe  computer  with 
batch  and  interactive  capability  through  terminals 

Minicomputer 

Utilizes  a  LOGC  minicomputer  with  multiple  terminals 
capability  to  handle  processing  and  report  dissemin¬ 
ation.  Estimated  need  of  2-4  MB  of  local  memory 

Line  Printer 

Use  high  speed  line  (600  LPM)  printer  located  at 

LOGC  Computing  Center  and  with  each  remote 
terminal 

Card  Reader 

Use  50-200  CPM  Card  Reader  located  at  LOGC  Computing 
Center 

Tape  Drives 

Use  9-Track  tape  drives  located  at  LOGC  Computing 

Center  and  DPFO 

Disk  Drives 

Use  DPFOs  and  LOGC  disk  drives  and  disks  for  support 
of  TRADES.  Minimum  of  90  MB  storage  capability 

initially 

Microcomputers  or 

Use  microcomputer  and  any  interactive  terminal  with 

Interactive  Terminals 

communications  equipment  for  interactive  operations 

Security  Equipment 

Use  in-place  KG  device  for  I/O  transactions 

Communications 

Equipment 

Use  a  4800  Baud  dedicated  line  from  the  TRADES 

Office  via  the  PFDB-TRADE  minicomputer  office  to 

DPFO  and  other  computer  ports  for  interactive 
processing 

Multiplexers 

Asynchronous,  minimum  of  eight  (8)  communications 
lines 

Modems  Modems  and  cables  as  necessary  for  multiplexer  re¬ 

quirement.  Also  needed  with  each  terminal /mini¬ 
computer  _ 

Graphics  Terminals  Graphics  terminals  and  plotting  equipment,  prefer¬ 
ably  color  systems,  for  requirements  and  performance 
charting 
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ACO 

ADP 

ADPE 

ARA 

COEA 

COMRAM 

CTDCS 

DBMS 

DFSR 

DLSIE 

DPFO 

DT 

DTIC 

EEA 
EE  I 

FP 

FTS 

ILS 

LOS 

LSAR 

MP 

MTBF 

MTBOMF 

MTBUMA 

MTD 

MTTR 

OAD 

OT 

OTEA 

PA 

PFDB 

PFMD 

PM 

PO 

RAM 


Alternative  Concept  of  Operation 
Automatic  Data  Processing 
Automatic  Data  Processing  Equipment 
Assigned  Responsible  Agency 

Cost  and  Operational  Effectiveness  Analysis 
Common  RAM 

Common  Test  Data  Collection  System 

Data  Base  Management  System 
Detailed  Functional  System  Requirements 
Defense  Logistics  Services  Information  Exchange 
Data  Processing  Field  Office 
Development  Test 

Defense  Technical  Information  Center 

Essential  Elements  of  Analysis 
Essential  Elements  of  Information 

Functional  Proponent 
Federal  Telephone  Service 

Integrated  Logistic  Support 

Logistics  Oriented  School 
Logistics  Support  Analysis  Record 

Management  Plan 
Mean  Time  Between  Failure 

Mean  Time  Between  Operational  Mission  Failure 
Mean  Time  Between  Unscheduled  Maintenance  Actions 
Maintenance  Task  Demand 
Mean  Time  to  Repair 

i 

Operations  Analysis  Directorate 
Operational  Test 

Operational  Test  and  Evaluation  Agency 

Proponent  Agent 

Planning  Factors  Data  Base 

Planning  Factors  Management  Division 

Project  Manager 

Project  Officer 

Reliability,  Availability,  Maintainability 
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SAG 

SAMF 

SAMI 

SAMS 

SDC 

SDP 

SRD 

STP 

SWP 


Study  Advisory  Group 
Stand-Alone  Mainframe 
Stand-Alone  Minicomputer 
Standard  Army  Maintenance  System 
Sample  Data  Collection 
System  Decision  Paper 
System  Requirements  Description 
System  Technical  Paper 
Study  Work  Plan 


TRADES 


TRADOC  RAM  Data  Evaluation  System 


